Public: User Documentation : February 21 2006 Dev Workshop Notes

The second call to this method does something odd, making sleds run faster in subsequent simulations the second time and thereafter (not cumulative). There seems to be a static call/side effect. Ed is looking into it.

needScreenResolution is a private static float, which explains it's global effect. It seems to set delta differently depending on whether or not it has a world value.

Multiple Force Problem

In Lake, the user can draw multiple forces, and John hacked the code to just use the first force the user drew. We'd like the user to just draw 1 arrow and be able to edit that 1 arrow. Qing sent the following solution, which seems to fix the problem:

1) in node Lake (the top node of a set of nested nodes), scroll down to the bottom of the script and look for the line sledForce.setDragMode(GUIPanel.DRAG_MODE_FORCE); (about 5 lines up from the bottom). Comment it out.

2) also in node Lake, up at the top, in startHandler, look for var currentForce = sledForce.getNthForce(0); and change it to var currentForce = sledForce.getForce();

Explanation: the first command set the mode to multiple forces, so commenting it out reset it to the default, which is one force. The command getNthForce doesn't work in that mode, though, hence the second change.

Debug Mode Changes and Other Bug Fixes

Zaz added conditionals in the code for debugging, to allow the user to just click through without selecting values or entering input.

Patti fixed some of the layout on Lake to make the layouts not "jump" on transitions.

Zaz did some refactoring so that the warning text handling for Lake matched up with how they're handled for the other module.

Ed is trying to change ACE so it doesn't generate new component names all of the time.

Logging

We need to know if implementation study sites will have full internet access. If yes, and they are reliable enough, we can use Concord's portal. Ed would like to configure something with javamail to send logs to a particular location.

For pilot test with 4-6 kids, we'll give each kid a separate JNLP file with a different ID in it. When they run, the log will be saved to CC's server and they can retrieve it for us by the ID from the JNLP file. The sample runMtnRescueLog.jnlp file that is checked in has the values that we need.

For now, to test logging during development, run runMtnRescueLog.jnlp and look at the Java Web Start Console to see that items are being logged. Ed will look into a way to make it so that the console can be saved to the local disk as a backup to what will also be saved on the CC server database.

<!-- LOGGING -->
<property name="org.concord.logging.logger.name" value="CC"/>
<property name="java.util.logging.manager.altclassloader" value="true"/>
<property name="java.util.logging.config.class" value="org.concord.logging.LogBootstrap"/>
        
<!-- CC has reserved the following ID's for the calipers project -->
<!-- user_id: 300000-300999 -->
<!-- class_id: 300000 -->
<!-- activity_id: 300000-300999 -->
<!-- activity_instance=activity_id -->

<!-- Change the user_id for each pilot test user -->
<property name="org.concord.pedagogica.user_id" value="300000"/>
<property name="org.concord.pedagogica.class_id" value="300000"/>
<property name="org.concord.pedagogica.topic_id" value="300000"/>
        
<!-- Change the activity_id and activity_instance_id for each activity -->
<property name="org.concord.pedagogica.activity_id" value="300000"/>
<property name="org.concord.pedagogica.activity_instance_id" value="300000"/>

Next, we walked through the activity determine what needed to be logged. Transitions and anything that is in the Assessment package is logged explicitly. We need to find all the these that aren't logged explicitly and change them to Assessment objects or add manual logging.

Logging Run/Reset buttons: We'll make explicit calls to the logger. Ed helped us identify how to do this, and we added this method to call for logging:

function logAction(message) {
   if (logger instanceof Packages.org.concord.logging.LoggerCC) {
      logger.logAction(0, message);
   }
}

Patti went through the code and logged all of the Run/Start/Reset button presses.

Logging radio buttons: We should use org.concord.assessment.MultipleChoice. Alternately we might be able to use existing JRadioButtons (e.g.,, if layout is an issue) by doing the following: create an instance of CustomChoiceQuestion and add JButton components (give it an abstract button array of buttons) and button group to that. See Time node for example; but we didn't get it to work. We might just convert all radio buttons to MultipleChoice and not worry that the layout may not look as good (be as controllable). Zaz did this for the Pasture pages, so this only needs to be done for the choose formula pages; Zaz will do this.

Logging the tiny text fields that people type numbers into: CustomChoiceQuestion or BlankFill might work (EssayFill would have a scroll bar and we don't want that). We had problems with CustomChoiceQuestions (see above) and determined that BlankFill doesn't work well for our purposes (you create BlankFills with a bunch of text with underscores in it, which are converted to text areas and logging saves the entire text, but ours have no text context since we use separate labels for units, so BlankFill wouldn't give us anything but a number, not even indicating what position/component it was). This is a longwinded way of saying that we decided to to manual logging for tiny text areas, calling logAction with the equation position and values in the exit method of the relevant nodes. Patti did this for all numerical entry fields.

Sliders: Patti used manual logging to log the values of all of the sliders on exit from a node.

Simulation force arrows: Log force arrows manually by inserting following code in handler that runs when student presses run.

var currentForce = sledForce.getForce();
					
// log force that the student drew
logAction("Force magnitude: " + currentForce.getMagnitude());
logAction("Force x: " + currentForce.getProjectionX());
logAction("Force y: " + currentForce.getProjectionY());

Notes from Ed's February 20, 2006 Visit

Agenda items

SetNeedScreenResolution bug

Multiple Force Problem

Debug Mode Changes and Other Bug Fixes

Logging

Fish World Update